Modernización de software

De Wikipedia, la enciclopedia libre


La modernización de sistemas heredados, también conocida como modernización de software o modernización de plataforma, se refiere a la conversión, reescritura o portación de un sistema heredado a un lenguaje de programación de computadora, librerías de software, protocolos o plataforma de hardware modernos. La transformación de sistemas heredados tiene como objetivo retener y extender el valor de la inversión heredada a través de la migración a nuevas plataformas para beneficiarse de las ventajas de las nuevas tecnologías.[1]​

Estrategias[editar]

La toma de decisiones de modernización de software es un proceso dentro de algún contexto organizacional. La toma de decisiones del “mundo real” en las organizaciones empresariales a menudo debe basarse en una “racionalidad limitada”.[2]​ Además de eso, existen múltiples (y posiblemente conflictivos) criterios de decisión; la certeza, la integridad y la disponibilidad de información útil (como base para la decisión) suelen ser limitadas.

La modernización de sistemas heredados es a menudo un proyecto grande y de varios años. Debido a que estos sistemas heredados a menudo son críticos en las operaciones de la mayoría de las empresas, la implementación del sistema modernizado de una sola vez introduce un nivel inaceptable de riesgo operativo. Como resultado, los sistemas heredados generalmente se modernizan de manera incremental. Inicialmente, el sistema consta completamente de código heredado. A medida que se completa cada incremento, el porcentaje de código heredado disminuye. Finalmente, el sistema se moderniza por completo. Una estrategia de migración debe garantizar que el sistema siga siendo completamente funcional durante el esfuerzo de modernización.

Estrategias de modernización[editar]

Existen diferentes impulsores y estrategias para la modernización del software:

  • Architecture Driven Modernization (ADM) es la iniciativa para estandarizar las vistas de los sistemas existentes con el fin de permitir actividades de modernización comunes como el análisis y la comprensión de código y la transformación del software.
  • Enfoque de enfoque empresarial: la estrategia de modernización está vinculada al valor empresarial añadido por la modernización. Implica definir la intersección de la criticidad para el negocio de una aplicación con su calidad técnica.[1]​ Este enfoque impulsado por Gartner coloca el Análisis de la Cartera de Aplicaciones (APA) como un requisito previo de las decisiones de modernización de una cartera de aplicaciones para medir el estado, los riesgos, la complejidad y el costo del software, proporcionando información sobre las fortalezas y debilidades de las aplicaciones.[3]​
  • La ingeniería dirigida por modelos (MDE) se está investigando como un enfoque para la ingeniería inversa que pueda luego usarse para ingeniería directa.[4]​[5]​[6]​
  • Renaissance:[7]​ método para evaluar iterativamente sistemas heredados, desde perspectivas técnicas, comerciales y organizacionales.
  • WMU (Warrants, Maintenance, Upgrade) es un modelo para elegir las estrategias de mantenimiento adecuadas según el nivel esperado de satisfacción del cliente y sus efectos en él.[8]​[9]​

Gestión de riesgos de modernización[editar]

La modernización del software es un proceso arriesgado, difícil, largo y altamente intelectual que involucra a múltiples partes interesadas. Las tareas de modernización del software están respaldadas por diversas herramientas relacionadas con la arquitectura basada en modelos de la OMG (Grupo de gestión de objetos) y procesos como ISO/IEC 14764:2006 o la técnica de migración y reutilización orientada a servicios (SMART).[10]​ La modernización del software implica diversas tareas manuales y automatizadas realizadas por trabajadores del conocimiento especializados. Las herramientas apoyan las tareas de los participantes del proyecto y ayudan a organizar la colaboración y la secuenciación del trabajo.

Un enfoque general de gestión de la modernización del software[11]​ tiene en cuenta los riesgos (tanto los tecnológicos como los de los objetivos del negocio) y consiste en:

  • Analizar la cartera existente: midiendo la calidad técnica y el valor empresarial. Confrontando la calidad técnica con los objetivos comerciales para definir la estrategia correcta: reemplazar, no migrar, prioridad baja, buen candidato.
  • Identificar a las partes interesadas: todas las personas involucradas en la modernización del software: desarrolladores, testers, clientes, usuarios finales, arquitectos, etc.
  • Comprender los requisitos: los requisitos se dividen en 4 categorías: de usuario, de sistema, limitaciones y no funcionales.
  • Crear el caso de negocio: el caso de negocio da soporte al proceso de decisión al considerar diferentes enfoques cuando los tomadores de decisiones lo necesitan.
  • Comprender el sistema que se va a modernizar: este es un paso crítico ya que la documentación del software rara vez está actualizada y los proyectos son realizados por numerosos equipos, tanto internos como externos y generalmente fuera de la vista durante mucho tiempo. Extraer el contenido de la aplicación y el diseño de su arquitectura ayudan a razonar sobre el sistema.
  • Comprender y evaluar la tecnología objetivo: esto permite comparar y contrastar tecnologías y capacidades con los requisitos y el sistema existente.
  • Definir estrategia de modernización: la estrategia define el proceso de transformación. Esta estrategia debe adaptarse a los cambios que ocurren durante el proceso de modernización (cambios de tecnología, conocimiento adicional, evolución de requisitos).
  • Conciliar la estrategia con las necesidades de las partes interesadas: las partes interesadas implícitas pueden tener diferentes opiniones sobre lo que es importante y cuál es la mejor manera de proceder. Es importante tener un consenso entre las partes interesadas.
  • Estimar recursos: cuando se definen los pasos anteriores se pueden evaluar los costos. Esto permite a la dirección determinar si la estrategia de modernización es viable dados los recursos y limitaciones disponibles.

Costos de modernización[editar]

  • Softcalc (Sneed, 1995a) es un modelo y herramienta para estimar costos de solicitudes de mantenimiento entrantes, desarrollado con base en COCOMO y FPA.
  • EMEE (Estimación del esfuerzo de mantenimiento temprano o "Early Maintenance Effort Estimation" en inglés)[12]​[13]​ es un nuevo enfoque para la estimación rápida del esfuerzo de mantenimiento antes de comenzar el mantenimiento real.
  • RENAISSANCE es un método para apoyar la evolución del sistema recuperando primero una base estable mediante la reingeniería y, posteriormente, mejorando continuamente el sistema mediante una serie de cambios incrementales. El enfoque se integra con éxito con diferentes procesos de gestión de proyectos[14]​

Desafíos en la modernización de sistemas heredados[editar]

Los principales problemas con un sistema heredado incluyen sistemas muy antiguos con falta de documentación, falta de expertos/conocimiento sobre los sistemas heredados y escasez de habilidades tecnológicas en las que se han implementado los sistemas heredados. Los sistemas heredados típicos existen desde hace más de dos décadas. La migración está plagada de desafíos:

  • Falta de visibilidad en grandes carteras de aplicaciones: las grandes organizaciones de TI tienen cientos, si no miles, de sistemas de software. La tecnología y el conocimiento funcional están por naturaleza distribuidos, diluidos y opacos. Ningún punto central de visibilidad para la alta dirección y los arquitectos empresariales es un problema principal: es un desafío tomar decisiones de modernización sobre los sistemas de software sin tener los datos cuantitativos y cualitativos necesarios sobre estos sistemas en toda la empresa.
  • Gestión de cambios organizativos: los usuarios deben volver a capacitarse y equiparse para usar y comprender las nuevas aplicaciones y plataformas de manera efectiva.
  • Coexistencia de sistemas heredados y nuevos: las organizaciones con una gran cantidad de sistemas heredados no pueden migrar de una sola vez. Es necesario adoptar un enfoque de modernización por etapas. Sin embargo, esto trae su propio conjunto de desafíos, como la proporción de una cobertura del negocio completa con una funcionalidad superpuesta bien entendida e implementada, duplicación de datos y desarrollo de sistemas desechables para unir los sistemas heredados con los nuevos durante las fases intermedias.[15]​
  • Gestión deficiente de la calidad estructural (ver calidad del software): lo que resulta en una aplicación modernizada que conlleva más problemas de seguridad, rendimiento, confiabilidad y mantenimiento que el sistema original.
  • Costos y duración significativos de la modernización: la modernización de un sistema heredado complejo de misión crítica puede requerir grandes inversiones y tener un sistema modernizado en pleno funcionamiento podría tomar años, sin mencionar las incertidumbres imprevistas en el proceso.
  • Compromiso de las partes interesadas: las principales partes interesadas de la organización deben estar convencidas de la inversión que se está realizando para la modernización, ya que los beneficios y un ROI inmediato pueden no ser visibles en comparación con los costos de modernización que se están invirtiendo.
  • Composición del software: es extremadamente raro que los desarrolladores creen código 100% original en estos días en cualquier cosa construida después de 2010.[16]​ A menudo utilizan marcos y componentes de software de código abierto y de terceros para ganar eficiencia, velocidad y capacidad de reutilización. Esto introduce dos riesgos: 1.) vulnerabilidades dentro del código de terceros y 2.) riesgo de licencias de código abierto.

Por último, pero no menos importante, no existe una solución única que se adapte a todos los tipos de opciones de modernización. Con una multitud de opciones comerciales y personalizadas disponibles para la modernización, es fundamental que los clientes, los vendedores y los ejecutores comprendan las complejidades de las diversas técnicas de modernización, sus mejores implementaciones aplicables, la idoneidad en un contexto particular y las mejores prácticas a seguir antes de seleccionar el enfoque de modernización adecuado.

Opciones de modernización[editar]

A lo largo de los años, han surgido varias opciones diferentes para la modernización de sistemas heredados; cada una de ellas tuvo un éxito y una adopción variables. Incluso ahora, existe una gama de posibilidades, como se explica a continuación, y no existe "la opción" para todas las iniciativas de transformación heredadas.

  • Evaluación de aplicaciones: Basar la cartera de aplicaciones existente utilizando inteligencia de software para comprender el estado, la calidad, la composición, la complejidad y la preparación de la nube del software para comenzar a segmentar y priorizar aplicaciones para varias opciones de modernización.
  • Descubrimiento de aplicaciones : Los componentes de las aplicaciones están fuertemente entrelazados, lo que implica un requisito para comprender la complejidad y resolver las interdependencias de los componentes de software.
  • Migración: migración de idiomas (3GL o 4GL), bases de datos (heredado a RDBMS y de un RDBMS a otro), plataforma (de un sistema operativo a otro sistema operativo), a menudo utilizando analizadores y convertidores automatizados para una alta eficiencia. Esta es una forma rápida y rentable de transformar los sistemas heredados.
  • Migración a la nube: migración de aplicaciones heredadas a plataformas en la nube que a menudo utilizan una metodología como la metodología de las 5 R de Gartner para segmentar y priorizar aplicaciones en diferentes modelos (Rehost, Refactor, Revise, Rebuild, Replace).
  • Reingeniería: una técnica para reconstruir aplicaciones heredadas en nueva tecnología o plataforma, con la misma funcionalidad o mejorada, generalmente mediante la adopción de Arquitectura Orientada a Servicios (SOA). Esta es la forma más eficiente y ágil de transformar aplicaciones heredadas.[4]​ Esto requiere inteligencia de software a nivel de aplicación con sistemas heredados que no son bien conocidos ni documentados.
  • Rehospedaje: ejecutar las aplicaciones heredadas, sin cambios importantes, en una plataforma diferente. La lógica empresarial se conserva a medida que la aplicación y los datos se migran al entorno abierto. Esta opción solo necesita el reemplazo de middleware, hardware, sistema operativo y base de datos.[17]​ Esto se usa a menudo como un paso intermedio para eliminar el hardware antiguo y costoso. Los ejemplos más comunes incluyen aplicaciones de mainframe que se vuelven a alojar en la plataforma UNIX o Wintel .
  • Implementación de paquetes: Reemplazo de aplicaciones heredadas, en su totalidad o en parte, con software estándar (COTS) como ERP, CRM, SCM, software de facturación, etc.[18]​

Un código heredado es cualquier aplicación basada en tecnologías y hardware más antiguos, como mainframes, que continúa brindando servicios básicos a una organización. Las aplicaciones heredadas suelen ser grandes y difíciles de modificar, y eliminarlas o reemplazarlas a menudo significa rediseñar los procesos de negocio de una organización. Sin embargo, cada vez más aplicaciones que se escribieron en los llamados lenguajes modernos como Java se están volviendo heredadas. Mientras que los lenguajes 'heredados' como COBOL ocupan los primeros lugares en la lista de lo que se consideraría heredado, el software escrito en lenguajes más nuevos puede ser igual de monolítico, difícil de modificar y, por tanto, candidato a proyectos de modernización.

Volver a implementar aplicaciones en nuevas plataformas de esta manera puede reducir los costos operativos, y las capacidades adicionales de las nuevas tecnologías pueden proporcionar acceso a funciones como servicios web y entornos de desarrollo integrados.[5]​ Una vez que se completa la transformación y se alcanza la equivalencia funcional, las aplicaciones se pueden alinear más estrechamente con las necesidades actuales y futuras del negocio mediante la adición de nuevas funciones a la aplicación transformada. El reciente desarrollo de nuevas tecnologías, como la transformación de programas por parte de empresas de modernización de software, ha hecho que el proceso de transformación de sistemas heredados sea una forma rentable y precisa de preservar las inversiones heredadas y, por lo tanto, evitar los costos y el impacto comercial de la migración a software completamente nuevo.

El objetivo de la transformación de sistemas heredados es retener el valor del activo heredado en la nueva plataforma . En la práctica, esta transformación puede tomar varias formas. Por ejemplo, podría implicar la traducción del código fuente o algún nivel de reutilización del código existente más una capacidad Web para proporcionar el acceso de cliente requerido por la empresa. Si es necesaria una reescritura, las reglas de negocio existentes se pueden extraer para formar parte de la especificación de requisitos para una reescritura.

Migración de software[editar]

La migración de software es el proceso de pasar del uso de un entorno operativo a otro entorno operativo que, en la mayoría de los casos, se cree que es mejor. Por ejemplo, pasar de Windows NT Server a Windows 2000 Server normalmente se consideraría una migración porque implica asegurarse de que se aprovechen las nuevas funciones, que no sea necesario cambiar la configuración anterior y tomar medidas para garantizar que las aplicaciones actuales sigan funcionando en la nueva. ambiente. La migración también podría significar pasar de Windows NT a un sistema operativo basado en UNIX (o al revés). La migración puede implicar el cambio a nuevo hardware, nuevo software o ambos. La migración puede ser a pequeña escala, como la migración de un solo sistema, o a gran escala, que involucra muchos sistemas, nuevas aplicaciones o una red rediseñada.[19]​

Véase también[editar]

Referencias[editar]

  1. ↑ a b Gardner, D: "Not just a nip and tuck, application modernization extends the lifecycle of legacy code assets", ZDNet, October 24, 2006
  2. ↑ «Simon’s Bounded Rationality. Origins and use in Economic Theory». Archivado desde el original el 22 de julio de 2011. Consultado el 24 de agosto de 2020. 
  3. ↑ Stefan Van Der Zijden; Thomas Klinect. Building a Multiplatform Application Modernization Business Case. 
  4. ↑ a b Menychtas, Andreas; Santzaridou, Christina; Kousiouris, George; Varvarigou, Theodora; Orue-Echevarria, Leire; Alonso, Juncal; Gorronogoitia, Jesus; Bruneliere, Hugo (2013), «ARTIST Methodology and Framework: A Novel Approach for the Migration of Legacy Software on the Cloud», 2013 15th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, 15th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (SYNASC), IEEE, pp. 424-431, ISBN 978-1-4799-3036-4, doi:10.1109/SYNASC.2013.62 .
  5. ↑ a b Menychtas, Andreas; Konstanteli, Kleopatra; Alonso, Juncal; Orue-Echevarria, Leire; Gorronogoitia, Jesus; Kousiouris, George; Santzaridou, Christina; Bruneliere, Hugo (2014), «Software modernization and cloudification using the ARTIST migration methodology and framework», Scalable Computing: Practice and Experience 15 (2), doi:10.12694/scpe.v15i2.980 .
  6. ↑ The ARTIST research project
  7. ↑ Ian Warren; Jane Ransom (2002). «Renaissance: A Method to Support Software System Evolution». 26th Annual International Computer Software and Applications Conference. pp. 415-420. ISBN 978-0-7695-1727-8. doi:10.1109/CMPSAC.2002.1045037. 
  8. ↑ Izzet Sahin; Fatemeh ‘Mariam’ Zahedi (2001). «Policy analysis for warranty, maintenance, and upgrade of software systems». Journal of Software Maintenance: Research and Practice 13 (6): 469-493. doi:10.1002/smr.242. 
  9. ↑ Jussi Koskinen; Jarmo Ahonen; Heikki Lintinen; Henna Sivula; Tero Tilus. Estimation of the Business Value of Software Modernizations. 
  10. ↑ Lewis, G.; Morris, E.; Smith, D.; O'Brien, L. (2005). «Service-Oriented Migration and Reuse Technique (SMART)». 13th IEEE International Workshop on Software Technology and Engineering Practice (STEP'05). pp. 222-229. ISBN 0-7695-2639-X. doi:10.1109/step.2005.24. 
  11. ↑ Lewis, Grace A.; Plakosh, Daniel; Seacord, Robert C. (2003). Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices. Addison-Wesley Professional. p. 27–37. ISBN 0321118847. 
  12. ↑ Andrea De Lucia; Eugenio Pompella; Silvio Stefanucci (July 2002). «Effort Estimation for Corrective Software Maintenance». Proceedings of the 14th international conference on Software engineering and knowledge engineering - SEKE '02. SEKE '02 Ischia, Italy. p. 409. ISBN 978-1581135565. doi:10.1145/568760.568831. 
  13. ↑ De Lucia, A.; Fasolino, A.R.; Pompelle, E. (2001). «A decisional framework for legacy system management». Proceedings IEEE International Conference on Software Maintenance. ICSM 2001. pp. 642-651. ISBN 0-7695-1189-9. doi:10.1109/ICSM.2001.972781. 
  14. ↑ Koskinen, Jussi; Lintinen, Heikki; Sivula, Henna; Tilus, Tero. «Evaluation of Software Modernization Estimation Methods Using NIMSAD Meta Framework». Publications of the Information Technology Research Institute. 
  15. ↑ Santhosh G. Ramakrishna (May 2007). «Logistics Legacy Modernization». Infosys Technologies Limited. 
  16. ↑ C. Ghezzi (2018). «Supporting Dependable Evolution». En Gruhn, Volker; Striemer, Rüdiger, eds. The Essence of Software Engineering. pp. 32-33. ISBN 978-3-319-73897-0. doi:10.1007/978-3-319-73897-0. 
  17. ↑ «Mainframe Modernization in a Nutshell». Modernization Hub (en inglés estadounidense). Archivado desde el original el 11 de mayo de 2021. Consultado el 23 de agosto de 2017. 
  18. ↑ Series, A. S. (ISO 9001:2008).
  19. ↑ SearchCIO.com
Obtenido de «https://es.wikipedia.org/w/index.php?title=Modernización_de_software&oldid=155135524»